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Specifying  Functional  and  Timing  Behavior 

for  Real-Time  Applications 


Abstract 


We  present  a  notation  and  a  methodology  for  specifying  the  functional  and  timing 
behavior  of  real-time  applications  for  a  heterogeneous  machine.  In  our  methodology 
we  build  upon  well-defined,  though  isolated,  pieces  of  previous  work:  Larch  and  Real 
Time  Logic.  In  our  notation,  we  strive  to  keep  separate  the  functional  specification 
from  the  timing  specification  so  that  a  task's  functionality  can  be  understood  inde¬ 
pendent  of  its  timing  behavior.  We  show  that  while  there  is  a  clean  separation  of 
concerns  between  these  two  specifications,  the  semantics  of  both  pieces  as  well  as 

their  combination  are  simple  -  -7  ,  1  - 
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1  Problem  Context 

Many  computation-intensive,  real-time  appRcations  require  efficient  concurrent  execution  of  multiple  tasks 
devoted  to  specific  pieces  of  the  appficatfon.  Typical  tasks  include  sensor  data  cotiection,  obstacle 
recognition,  and  global  path  planning,  In  applications  such  as  robotics  and  vehicular  control.  Since  the 
speed  and  throughput  required  of  each  task  may  vary,  these  applications  can  best  exploit  a  computing 
environment  consisting  of  multiple  special  and  general  purpose  processors  that  are  logically,  though  not 
necessarily  physically,  loosely  connected.  We  cal  this  environment  a  heterogeneous  machine. 

During  execution  time,  processes,  which  are  instances  of  tasks,  run  on  possibly  separate  processors,  and 
communicate  with  each  other  by  sending  messages  of  dHferent  types.  Since  the  patterns  of 
communication  can  vary  over  time,  and  the  speed  ot  the  individual  processors  can  vary  over  a  wide 
range,  additional  hardware  resources,  in  the  form  of  switching  networks  and  data  buffers  are  required  in 
the  physical  heterogeneous  machine.  Logically,  queues  are  used  to  buffer  data;  processes  dequeue  data 
on  queues  attached  to  input  ports  and  enqueue  data  from  queues  attached  to  output  ports. 

The  application  developer  is  responstile  for  prescribing  a  way  to  manage  afi  of  these  resources.  We  call 
this  prescription  a  task-level  application  deschptlon.  It  describes  the  tasks  to  be  executed,  tire  assignment 
of  processes  to  processors,  the  data  paths  between  the  processors,  and  the  intermediate  queues 
required  to  store  the  data  as  it  moves  from  source  to  destination  processes.  A  task-level  description 
language  is  a  notation  in  which  to  write  these  application  descriptions. 

We  are  using  the  term  'description  language*  rather  than  "programming  language*  to  emphasize  that  a 
task-level  application  description  is  not  translated  into  object  code  in  some  kind  of  executable  'machine 
language.*  Rather,  it  is  to  be  understood  as  a  description  of  the  structure  and  behavior  of  a  logical 
machine,  that  will  be  synthesized  into  resource  afiocation  and  scheduling  directives.  These  directives  are 
to  be  interpreted  by  a  combination  of  software,  firmware,  and  hardware  in  a  heterogeneous  machine. 

We  have  an  initial  design  of  such  a  description  language  [1],  a  compiler  for  It,  and  a  simulator  that  takes 
task  descriptions  as  input.  A  task  description  (see  Figure  1)  contains  information  about  four  aspects  of  a 
task:  (1)  its  interface  to  other  tasks  (ports)  and  to  the  scheduler  (signals),  (2)  its  functional  and  timing 
behavior,  (3)  its  attributes,  and  (4)  its  internal  structure,  thereby  slowing  for  hierarchical  task 
descriptions.  Reference  [1]  contains  a  more  complete  explanation  of  these  and  other  features  of  the 
language.  In  this  paper  we  focus  on  only  one  aspect:  the  information  appearing  in  the  behavior  part  of  a 
task  description. 

2  Contributions 

Formal  specifications  have  been  used  successfully  for  specifying  the  functional  behavior  of  software 
systems,  e.g.,  Individual  program  modules  and  abstract  data  types.  These  specifications  have 
traditionally  been  used  to  verify  a  program’s  correctness  (“is  the  right  answer  computed?”).  Often, 
however,  one  Is  interested  in  not  only  the  functional  correctness  of  a  system  but  also  other  properties, 
such  as  reliability,  performance,  security,  and  real-time  behavior.  Less  work  has  focused  on  formally 
specifying  these  other  properties  of  software  systems,  let  alone  their  interactions  with  each  other. 

To  our  knowledge  no  work  has  addressed  the  formal  integration  of  the  formal  specification  of  functional 
and  timing  behavior  of  software.  The  main  contribution  of  this  paper  is  exactly  this  integration  of 
functional  and  timing  specifications  as  embodied  in  our  task  description  language. 


—  0*«d  fee 


—  Deed  for  ui— in  I  nation  between  e  user  preoese  end  the  scheduler 

—  1  description  of  the  fuaetionel  and  tlslag  behavior  of  the  task 


—  Additional  properties  of  the  task 
—  A  process -queue  graph  describing  the  internal  structure  of  a  task 


Figure  1 :  A  Template  for  Task  Descriptions 


We  combine  two  separate  formalisms:  an  axiomatic  specification  language,  Larch  [11, 12],  used  to 
specify  functional  behavior,  and  an  event  expression  language  used  to  specify  timing  behavior.  Both  are 
mapped  to  the  same  underlying  logic,  typed  first-order  predicate  logic,  so  that  their  combination  has  a 
formal  semantics. 

Two  significant  aspects  of  our  work  are  as  follows: 

•  Since  the  formal  semantics  is  relatively  simple  (first-order  logic),  not  only  can  people  easily 
understand  our  specifications  but  the  specifications  themselves  can  easily  be  subject  to 
machine  analysis. 

•  We  build  upon  previous  wen  defined  and  isolated  pieces  of  research  and  combine  them  in  a 
meaningful  way.  Their  combination  is  applied  in  a  context  (heterogeneous  machines)  that 
itself  is  of  growing  interest  to  those  involved  in  parallel  architectures  and  languages. 

3  Introduction  to  Larch 

Before  we  describe  the  functional  and  timing  specifications  of  a  task,  we  give  a  brief  introduction  to 
Larch1. 

Larch  uses  a  two-tiered  approach  to  specifying  program  modules:  a  trait  defines  state-independent 
properties,  and  an  interface  specification  defines  state-dependent  properties  of  a  program.  A  trait  is 
written  in  the  Larch  Shared  Language  (LSL),  and  it  provides  the  assertion  language  used  to  express  and 
define  the  meaning  of  the  predicates  of  an  interface  specification. 

For  a  program  module,  such  as  a  procedure,  a  Larch  interface  specification  is  written  in  a  Larch  Interface 
Language  (LIL)  and  contains  predicates  about  the  states  before  and  after  the  execution  of  the  procedure. 
The  Larch  Interface  Language  to  be  used  is  specific  to  the  programming  language  in  which  the  procedure 
is  written  (e  g.,  C,  CommonUsp,  Ada,  etc.).  For  this  paper  we  will  use  a  relatively  simple  interface 
language,  such  as  would  be  defined  for  an  Algol-like  language. 


’W#  are  Imping  this  introduction  to  Larch  very  short  The  rsadsr  is  encouraged  to  consult  ths  appropriate  references  in  the 
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b.  Interfaces  for  Queue  Operations 


Figure  2:  A  Larch  Two-Tiered  Specification  for  Queues 


Figure  2  depicts  a  Larch  (two-tiered)  specification  of  queues  with  Enqueue  and  Dequeue  operations.  The 
top  part  of  the  specification  (Figure  2.a)  is  a  trait  written  in  LSL  used  to  describe  values  of  queues.  A  trait 
is  akin  to  an  algebraic  specification  (see  Section  7  on  Related  Work).  A  set  of  operators  and  their 
signatures  following  introduces  defines  a  vocabulary  of  terms  to  denote  values  of  a  type.  For  example. 
Empty  and  tnsert(Empty,  5)  denote  two  different  queue  values.  The  set  of  equations  following  the 
constrains  clause  defines  a  meaning  for  the  terms;  more  precisely,  an  equivalence  relation  on  the  terms, 
and  hence  on  the  values  they  denote.  For  example,  from  the  above  trait,  one  could  prove  that 
First(Rest(lnsert(lnsert(Empty,  5),  6)))  -  6. 

The  bottom  part  of  the  specification  (Figure  2.b)  contains  two  interfaces  written  in  our  “generic”  Larch 
interface  language.  They  describe  the  functional  behavior  of  two  queue  operations,  Enqueue  and 
Dequeue  (queue  operation  names  are  used  to  write  timing  expressions,  which  are  described  later  in  this 
paper).  A  requires  is  a  pre-condition  on  the  state  of  an  operation's  input  data  that  must  be  tree  upon 
operation  invocation;  an  ensures  is  a  post-condition  on  the  state  of  an  operation's  input  and  output  data 
that  is  guaranteed  to  be  true  upon  operation  termination.  An  omitted  predicate  is  taken  to  be  true.  The 
specification  for  Dequeue  states  that  Dequeue  must  be  called  with  a  non-empty  queue  and  that  it 
modifies  the  original  queue  by  removing  its  first  element  and  returning  it. 
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s 
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4  Behavioral  Information 

The  behavioral  information  in  a  task  description  is  divided  into  two  parts:  a  functional  specification  and  a 
timing  specification.  In  the  next  two  subsections  we  describe  informally  the  syntax  and  meaning  of  these 
two  specifications.  Section  5  gives  the  formal  meaning,  and  in  particular,  the  meaning  of  the  combination 
of  functional  and  timing  specifications. 

4.1  Functional  Specifications 

4.1.1  Syntax  and  Meaning 

The  functional  information  of  a  task  description  (see  Figure  1 )  describes  the  behavior  of  the  task  in  terms 
of  predicates  about  the  data  in  the  queues,  before  and  after  each  execution  of  the  task,  it  consists  of  a 
requires  clause  and  an  ensures  clause,  together  constituting  a  simple  Larch  interface  specification.  LSL 
is  used  as  the  assertion  language  in  the  predicates  of  these  clauses. 

A  requires  clause  states  what  is  required  to  be  true  of  the  data  coming  through  the  input  ports;  an 
ensures  clause  states  what  is  guaranteed  to  be  true  of  the  data  going  out  through  the  output  ports.  If 
one  were  to  view  each  cycle  of  a  task  as  one  execution  of  a  procedure,  the  requires  and  ensures  are 
exactly  the  pre-  and  post-conditions  on  the  functionality  of  that  cycle. 

A  task  implementation  must  satisfy  the  predicates,  R  and  E,  of  the  requires  and  ensures  clauses.  A  task 
implementation  is  simply  a  program  written  in  some  programming  language,  e.g.,  C,  Common  Lisp,  or 
Ada.  Using  Hoare-like  notation,  an  implementation,  Prog,  satisfies  the  (functional)  specification  if: 

(R)  Prog  (E) 

It  is  up  to  the  task  implementor  to  show  that  a  task  implementation  satisfies  the  functional  specification  as 
given  by  the  requires  and  ensures  clauses.  This  verification  can  be  done  formally  —  standard 
verification  techniques  can  be  used  ([13, 14])  and  some  mechanical  tools  are  available  to  aid  this 
process  ( [9, 19, 22, 21]).  We  defer  to  Section  5.2  for  the  definition  of  the  meaning  of  the  predicates  in 
the  presence  of  timing  information. 

4.1.2  Example 

Consider  a  matrix  multiplication  task  (Figure  3)  that  takes  input  matrices  from  two  queues  and  outputs  the 
result  matrix  on  an  output  queue.  The  data  traveling  through  these  ports  are  of  type  matrix.  Matrix  values 
are  specified  using  LSL  just  as  for  queue  values,  so  “rows,”  “cols"  and  would  be  defined  in  a  trait 
about  matrix  values.  The  requires  clause  states  that  the  task  implementor  may  assume  that  the  number 
of  rows  of  the  matrix  entering  through  the  port  ini ,  equals  the  number  of  columns  of  the  matrix  entering 
through  in2.  The  ensures  clause  states  that  the  result  of  multiplying  the  two  input  matrices  is  output 
through  the  output  port. 

4.2  Timing  Specifications 

4.2.1  Syntax  and  Meaning 

The  timing  information  describes  the  behavior  of  the  task  in  terms  of  the  operations  that  it  performs  on  the 
queues  attached  to  its  input  and  output  ports;  this  is  the  behavior  of  the  task  seen  from  the  outside. 


Uak  Multiply 


ports 

ini,  io2:  In  Matrix; 
outl ;  owl  Matrix; 
behavior 

requires  cows  (First  (ini) )  ■  sola  (First  (ia2) ) 
tftsurss  Insart  (outl,  First  (ini)  *  First  (in2) ) 
end  aultiply 

Figure  3:  The  Functionality  of  a  Matrix  MuttipKcation  Task 


The  simplest  timing  expression  is  the  name  of  a  queue  operation,  e.g.,  Enqueue  or  Dequeue,  on  a  queue 
attached  to  a  specific  port,  e.g.,  ini.  The  duration  of  a  queue  operation  or  the  delay  between  two 
operations  is  described  by  a  time  window.  Time  windows  are  denoted  by  a  pair  of  time  values  Fmirv^maxl 
defining  the  boundaries  of  the  interval.  The  time  window  associated  with  a  queue  operation  describes  the 
minimum  and  maximum  time  needed  to  perform  the  operation.  Intervals  of  time  between  queue 
operations  are  denoted  by  a  Delay  “operation"  whose  time  window  describes  the  minimum  and  max'mum 
time  consumed  by  the  process  in  between  queue  operations. 

A  composite  timing  expression  denotes  the  sequential  and/or  concurrent  execution  of  operations  on 
queues.  Sequential  composition  is  denoted  by  a  space  between  operations;  parallel  composition  is 
denoted  by  a  “II”  between  operations.  For  example, 

loop  (in1.Dequeue(10,15]  ||  in2.  Dequeue)  detayf,30]  outl  .Enqueue 
is  a  sequential  timing  expression  that  specifies  two  parallel  Dequeue  operations  on  the  queues  attached 
to  the  input  ports  ini  and  in2  followed,  after  some  delay,  by  an  Enqueue  on  the  queue  attached  to  the 
output  port  outl.  The  Delay  lasts  some  undetermined  amount  of  time  less  than  30  seconds.  The 
Dequeue  operation  on  port  ini  takes  between  10  and  15  seconds  to  complete.  The  other  two  operations 
take  some  implementation  dependent  default  time  to  complete.  The  keyword  loop  denotes  a  cyclic  or 
repeating  task. 

An  optional  guard  in  a  timing  expression  specifies: 

1 .  the  number  of  times  the  task  is  to  be  executed:  “repeat  integer  ->  expression,"  or 

2.  during  what  time  interval  the  task  is  allowed  to  start:  " during  timewindow  «>  expression,"  or 

3.  the  earliest  allowable  start  time:  "after  timevalue  ->  expression,"  or 

4.  the  latest  allowable  start  time  "before  timevalue  *>  expression,"  or 

5.  a  predicate  on  the  state  of  the  input  queues  or  the  current  time  which  must  be  true  before 
the  task  is  allowed  to  start:  "when  predicate  ->  expression." 

In  our  examples,  we  will  often  drop  the  name  of  the  queue  operation  and  use  just  the  name  of  the  port 
(i.e.,  “ini"  instead  of  "ini .Dequeue").  Since  this  paper  introduces  only  two  queue  operations:  Enqueue 
and  Dequeue,  and  given  that  the  former  applies  only  to  input  queues  and  the  other  applies  only  to  output 
queues,  no  confusion  should  occur  as  to  which  operation  is  implied. 


4.2.2  Example 

Consider  a  matrix  multiplication  task  (Figure  4)  that  takes  input  matrices  from  two  queues  and  outputs  the 
result  matrix  on  an  output  queue.  The  timing  clause  stales  that  the  task  does  not  start  executing  until 
both  input  queues  contain  data  Once  that  condition  is  satisfied,  the  task  will  remove  its  input  data  from 
both  input  queues  concurrently  (the  Dequeue  operations),  will  operate  on  the  data  for  between  10  and  15 
seconds  (this  “computation”  time  is  lumped  together  under  the  delay  operation),  and  finally  will  enqueue 
some  output  in  the  output  queue.  Notice  another  use  of  LSL  in  our  specifications:  the  when  condition 
places  a  constraint  on  the  state  of  the  queues  (not  on  the  state  of  the  data  in  the  queues).  We  use  the 
trait  from  Section  3  to  define  the  assertion  language  for  predicates  in  a  when  guard. 

task  Multiply 
ports 

ini,  in2:  In  aatrix; 
entl:  out  Matrix; 
behavior 

requires  rows  (First  (ini) )  ■  ools  (First  (io2)) 
ensures  Insart (outl ,  First (ini)  *  First (in2)) 
timing  when  (>isbpty(itl)  and  ~isl^>t;(in2) )  ■> 

((ini. Dequeue  ||  in2. Dequeue)  delay [10, 15]  outl .Enqueue) 

end  Multiply 

Figure  4:  The  Timing  of  a  Matrix  Multiplication  Task 


5  Formal  Meaning  of  Functional  and  Timing  Specifications 

We  use  Jahanian  and  Mok's  Real-Time  Logic  (RTL)  [15]  to  give  meaning  to  our  timing  expressions. 
Furthermore,  we  use  their  logic  to  give  meaning  to  the  combination  of  our  functional  and  timing 
specifications.  We  use  four  of  their  notational  conventions: 

Syntax  Meaning 

tA  The  start  of  an  operation  ("action”  in  RTL’s  terminology). 

lA  The  end  of  an  operation. 

@(E,  i)  The  time  of  the  Ith  occurrence  of  event  E,  where  events  in  our  context  are  the  start  of 

an  operation  or  the  end  of  an  operation.  @  is  an  occurrence  function  that  captures 
the  notion  of  real-time. 

P(t1 ,  t2)  The  interval  of  time  during  which  the  predicate  P  holds.  P  holds  before  or  at  tl ,  from 

tl  to  t2,  and  at  or  after  t2.  If  tl  and  t2  are  identical,  then  P  holds  at  an  interval  around 
tl .  For  brevity,  we  will  use  P(t)  when  tl  -t2  (i.e.,  “P  holds  around  time  t"). 

5.1  Assigning  Meaning  to  Timing  Specifications 

In  this  section  we  describe  the  meaning  of  our  timing  specifications  in  terms  of  RTL  logic.  In  the  following 
discussion,  we  assume  E,  El,  and  E2  are  arbitrary  timing  expressions;  A,  A1,  and  A2  are  operations;  tl 
and  t2  we  times  (absolute  or  relative);  al  and  a2  are  absolute  times;  rl  and  r2  are  relative  times;  and  W 
is  a  predicate  of  a  when  guard. 

To  simplify  the  exposition,  we  introduce  a  simple  rewrite  rule:  Any  timing  expression  of  the  form  “repeat 
n  ->  E"  can  be  rewritten  as  a  sequence  of  n  occurrences  of  the  unguarded  expression  E  ("E  EE...  E”). 
Thus,  the  only  guards  we  need  to  oonsider  are  before,  after,  during,  and  when. 


We  also  introduce  the  following  axioms: 

1 .  For  any  queue  operation  A,  aid  for  some  implementation  defined  duration  T,  the  following 
axiom  expresses  the  duration  of  A: 

Vi[@(iA,i)-@(tA.i)-T] 

2.  For  any  queue  operation  Afll  ,t2],  with  a  duration  defined  by  the  time  window  [tl  ,t2],  the 
following  axiom  expresses  the  duration  of  A: 

V  i  I  tl  <;  @(lA,l)  -  @(tA,i)  £  t2 1 

3.  For  any  sequence  of  queue  operations,  A1  ...  An,  the  following  axiom  relates  the  start  and 
end  times  of  the  sequence  to  the  start  and  end  times  of  the  individual  operations: 

V  i  [@{tA,  i)  -  @<TA1 ,  i)  a  @(iA,  i)  -  @(iAn,  i)] 

4.  For  any  parallel  queue  operations,  A1  ||  ...||  An,  the  following  axiom  relates  the  start  and 
end  times  of  the  composition  to  the  start  and  end  times  of  the  individual  operations: 

V  i  [@(Ta,  i)  -  min(@(tA1,  i) . @(tAn,  i))  a  @(iA,  i)  «  max(@(iA1,  i) . @(iAn,  i))] 

5.  The  last  two  axioms  state  that  cycles  in  a  repeating  task  do  not  overlap.  Thus,  we  cannot 
have  an  input  operation  finish  after  any  of  the  output  operations  and  we  cannot  have  an 
output  operation  start  before  any  input  operation  starts: 

V  i  [  max(@(iout1,i),@(iou^,i) . @(ioutj,i))  >  max(@(iin1,i),@(lin2,i) . @>(!inK,i))  ] 

V  i  [  min(@(Tout1,i),@(Tout2.i)....,@(t  outj,i))  >  min(@(tin1,i),@(tin2.i) . @(tinK,i))  ] 

where  J  and  K  are  the  number  of  output  and  input  queues,  respectively. 

We  assign  a  meaning  to  timing  expressions  by  introducing  a  function,  M,  (Table  l.a),  which  maps  timing 
expressions  to  Boolean  values, 

M, :  Timing  Expression  -»  Boolean. 

We  use  an  auxiliary  function,  op  (Table  l.b),  which  maps  timing  expressions  to  operations, 

op:  Timing  Expression  -»  Operation. 

op  is  needed  because  "start  time”  and  “end  time”  are  meaningful  only  for  queue  operations. 

As  an  example  of  how  to  interpret  the  formalism  intuitively,  consider  the  entries  for  the  during  guard  in 
Table  1  .a.  They  specify  a  time  window  during  which  the  operation  is  allowed  to  start.  The  first  value  is 
the  earliest  start  time  allowed  and  must  be  an  absolute  time  value.  The  second  value  is  the  latest  start 
time  allowed  and  can  be  an  absolute  time  value  or  a  time  value  relative  to  the  former.  The  meaning  of  the 
guarded  expression  is  the  conjunction  of  the  meaning  of  the  expression  proper  and  a  predicate  stating 
the  restriction  on  starting  times. 

5.2  Assigning  Meaning  to  the  Combined  Specifications 

Given  a  task  description  of  the  form: 

task  taskname 

behavior 
requires  Req ; 
ensures  Ens ; 
timing  E ; 


end  taskname ; 


(Et) 

Et ...  En 
E1||...||En 
El  E2 
El  ||  E2 

when  W  ->  El 
before  at  ->  El 
after  al  ->  El 
during  [al,  a2]  ->  El 
during  [al,  r2)  ■>  El 
A[r1,r2] 

AT,  rl] 

A[r1,1 

A 

Timing  Expression 
loop  El 
El  ...  En 
El  ||...  ||  En 
Q  ■>  El 
A[t1.t2] 

A 


M,(E1) 

M,((E1  E2)  ...En) 
a  M,(Ei||Ej)  for  all  i  ^  j 

M,(E1)  a  M,(E2)  a  V  i  [  @(iop(E1),i)  S  @(top(E2),i)  ] 

M,(E1)  a  M|(E2)  a 

V  i  [  @(top(E1),  i)  <  @(lop(E2),i)  a  @(top(E2),i)  <  @(iop(E2),i)  ] 
Mj(E1)  a  V  i  [  W(@(top(E1),  i))] 

M,(E1)  a  V  i  [  @(top(E1),  it)  S  al  1 
M,(E1)  a  V I  [  @(top(E1),  I)  ^  al  ] 

Mt(E1 )  a  Vi[a1  s@(top(E1),  i)sa2] 

M,(E1)  a  VI [al  S@(top(E1),  i)«Sa1  +r2] 

V  i  [  @(tA,  I)  +  rl  5  @(iA,  I)  £  @(tA,  i)  +  r2  ] 

V  i  [  @(iA,  I)  5  @<Ta,  I)  +  rl  ] 

Vi[@(tA,i)  +  r1  S@(iA,  I)] 
true 

a.  Mapping  from  Timing  Expressions  to  Booleans 

oofExpression) 
op(  El) 

op( El) ...  op( En) 
op( El)  || ...  ||  op( En) 

op( El)  for  all  guards  Q  (when,  before,  during,  and  after). 

A 

A 

b.  Mapping  From  Timing  Expressions  to  Operations 


Table  1 :  Assigning  Meaning  to  Timing  Expressions 
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we  give  meaning  to  the  predicates  of  the  functional  specification  as  related  to  time  (i.e.,  at  what  times  are 
these  predtoates  to  hold?)  via  a  function  M,  which  maps  from  behavioral  specifications  to  Boolean  values: 

M| :  Predteate  x  Timing  Expression  -» Boolean 
Predicate  Timino  Expression  M^Predicate.  Expression) 

Req  E  V  i  [  Req(©(top(E).  i))  a  M,(E)  1 

Ens  E  V  i  [  Ens(@(ifljp(E),  I))  a  M,(E)  J 

The  function  M,  is  precisely  the  link  between  the  functional  and  timing  specifications.  This  link  is 
charactertzabie  purely  in  terms  of  first-order  logic. 


6  Examples 

Figure  5  shows  our  multiply  task  with  functional  and  timing  information  together.  The  figure  shows  two 
different  multiply  tasks,  specified  to  have  the  same  functionality  but  with  different  timing  behavior.  The 
timing  expression  in  Figure  S.a  states  that  the  multiply  task  first  checks  that  the  input  queues  are  non¬ 
empty,  and  if  so  perform  two  parallel  Dequeue  operations  foNowed  by  an  Enqueue  operation.  The  timing 
expression  in  Figure  5.b  states  that  the  inputs  come  in  sequentially  instead  of  in  parallel. 


task  Multiply 
port* 

ini,  1x2:  In  Matrix 
oatl:  out  Matrix 
behavior 

requires  rowa  (First  (ini) )  •  ools (First (1x2) ) 
ensures  insert (outl,  First (ini)  •  First (1x2)) 
timing  whan  (-laFxyity  (lnl)  and  -laftqity  (1x2) )  ■> 

( (ini .Dsqusus  ||  1x2. Dequeue)  daisy [10, IS]  eutl . Enqueue) 

a  Paraflei  input 


task  Multiply 
ports 

ini,  ia2:  In  Matrix 
ontl :  out  Matrix 
bahavfor 

requires  rows  (First  (ini))  »  ools  (First  ( ia2 ) ) 
on  suras  Insart  (<ratl,  First  (ini)  *  First  (ini)) 

timing  whan  (-iatapty (ini)  and  -isJWpty ( 1x2 ) )  ■> 

(lnl. Dequeue  1x2. Dequeue  daisy [10, 15)  <ratl . Inquana) 

b.  Serial  Input 

Figure  5:  Matrix  Multiplication  Task 


To  further  illustrate  the  richness  of  our  specification  language  and  to  show  the  benefits  of  cleanly 
separating  the  functional  from  the  timing  Information,  we  write  three  alternative  descriptions  tor  a  task  built 
into  our  library.  This  task,  deal,  has  one  input  port  and  a  number  of  output  ports.  Data  dequeued  from  the 
input  port  is  enqueued  to  one  of  the  output  ports,  but  this  can  be  implemented  in  a  number  of  ways,  as 
illustrated  in  Figure  6,  below2. 


*Assume  that  secondfinl),  1hM(in1),  and  fountain  1)  as  dabrevwnooa  lor  Fksi(Rset(tnl)).  Rnt(Rast<Rest(in1»>, 
FhHW—knaKh— Mini »»•  — pecSvely.  am  defined  in  Vw  trait  for  queuee 


The  first  example  (Figure  6. a)  states  that  we  alternate  the  dequeueing  of  input  and  enqueuing  of  output 
and  ensures  that  first  (second)  output  queue  wifi  see  the  first  (second)  item  removed  from  the  input 
queue.  The  second  example  (Figure  6.b)  states  that  we  dequeue  aH  input  before  the  output  operations 
start,  which  themselves  take  place  concurrently.  It  alows  for  the  first  dequeued  data  item  to  be  enqueued 
on  either  of  the  output  queues,  but  ensures  that  the  second  dequeued  item  will  not  be  enqueued  to  the 
same  as  the  first.  The  third  example  (Figure  6.c)  states  that  input  data  are  dequeued  and  grouped  in 
pairs  before  enqueues ng  them  into  the  output  ports.  The  first  pair  is  enqueued  to  the  first  output  queue; 
the  second  pair,  to  the  second. 

teak  4*tl 
ports 

ini :  In  aatsix; 
wtl,  mU:  out  aatrix; 
bohavior 

an  suras  Xnaart (outl,  First (ini) )  a  Insnrt (out 2 ,  aaoond(inl) ) 
timing  loop  (ini  outl  ini  out2) 

and  daal 

a  Alternating  input  and  Output 


task  daal 
ports 

ini :  In  aatrlx; 
outl,  out2:  out  aatrix; 
bohavior 

snsuraa  (Inaart (outl,  first (ini))  S  Xnsart ( ont2 ,  saoond(inl) ) ]  | 
[Znsart (out 2 ,  first (ini))  a  Znsart (outl,  aoeoud(inl) ) ] 
timing  loop  (ini  ial  (outl  1 1  out2)) 

ood  dual 

b  .  Concurrent  Output 


task  dual 
ports 

ini :  In  aatrix; 
outl,  out2:  out  aatrix; 
bahavior 

snsuraa  (Znsart (outl,  First (ini))  a  Insart (outl ,  sooond(inl) ) ) ]  a 
[ Znsart ( out2 ,  third (ini))  a  Znsart (out 2 ,  fourth (ini) ) ) 
timing  loop  (ial  ial  ini  ini  (outl  ||  out2)  (outl  ||  out2)) 

and  daal 

c.  Grouping  Data 
Figure  6:  Deal  Task 


7  Related  Work 

The  axiomatic  approach  to  specifying  a  program's  functional  behavior  has  its  origins  in  Hoare's  early  work 
on  verification  (1 3]  and  later  work  on  proofs  of  correctness  of  implementations  of  abstract  data  types  [1 4], 
where  first-order  predicate  logic  pre-  and  post-conditions  are  used  for  the  specification  of  each  operation 
of  the  type.  The  algebraic  approach,  which  defines  data  types  to  be  heterogeneous  algebras  [2],  uses 
axioms  to  specify  properties  of  programs  and  abstract  data  types,  but  the  axioms  are  restricted  to 
equations.  Much  work  has  been  done  on  algebraic  specifications  for  abstract  data  types 
[8.7,10,27,3,6,25.16];  we  use  more  recent  work  on  Larch  specifications  [11, 12]  for  program 
modules.  None  of  this  work  addresses  the  formal  specification  of  timing  behavior  of  systems. 


Operational  approaches,  such  as  those  based  on  Timed  Petri-net  models  [20, 23],  are  more  commonly 
used  for  specifying  behavior  of  real-time  systems.  Timed  Petri-nets  can  be  roughly  characterized  by 
whether  “operation”  time  is  assigned  to  foe  transitions,  as  in  the  original  model  by  Ramchandani  [20],  or 
is  assigned  to  the  places,  as  in  Sifakis'  model  [23].  in  addition,  both  deterministic  and  stochastic  timing 
are  allowed,  giving  origin  to  a  variety  of  models  for  specifying  or  evaluating  performance  requirements. 
This  has  been  illustrated  in  recent  work  by  Cooiahan  [4]  (places,  deterministic),  Smith  [24]  (transitions, 
deterministic),  Wong  [26]  (places,  stochastic),  and  Zuberek  [28]  (transitions,  stochastic).  In  contrast,  our 
work  takes  a  more  axiomatic  than  operational  approach  to  specifying  timing  behavior. 

Specification  and  verification  of  timing  requirements  for  real-time  systems  include  recent  work  by 
Dasarthy  [5],  and  by  Lee,  Gehlot,  and  Zwarico  [17, 29].  This  work  as  well  as  that  by  Jahanian  and  Mok, 
whose  real-time  logic  we  borrow,  all  focus  on  timing  properties  and  not  on  functional  behavior.  Either 
states  are  left  uninterpreted  or  predicates  on  states  are  simplistic,  e.g.,  boolean  modes  as  in  Jahanian 
and  Mok's  work.  In  contrast,  since  we  have  a  formal  means  of  specifying  the  functional  behavior  of  tasks 
and  foe  data  on  which  they  operate,  we  have  a  more  expressive  specification  language  with  a  richer 
semantics. 

8  Summary 

Our  approach  to  specifying  foe  functional  and  timing  behavior  of  real-time  applications  for  a 
heterogeneous  machine  has  the  following  characteristics: 

•  It  takes  advantage  of  two  well  defined,  though  isolated,  pieces  of  previous  work. 

•  There  is  a  dean  separation  of  concerns  between  the  two  specifications. 

•  The  semantics  of  both  specifications  as  well  as  their  combination  are  simple. 

In  our  language  design,  we  strove  to  separate  the  functional  specification  from  the  timing  specification  so 
that  a  task’s  functionality  could  be  understood  independent  of  its  timing  behavior.  This  separation  of 
concerns  gives  us  the  usual  advantages  of  modularity.  Different  timing  specifications  can  be  attached  to 
the  same  functional  specification.  Task  implementors  can  focus  on  satisfying  functionality  first,  timing 
second.  Task  validation  can  be  performed  separately.  For  example,  one  could  use  formal  verification  for 
functionality  and  simulation  for  timing. 

Since  the  semantics  can  be  given  in  terms  of  first-order  predicate  logic,  our  specifications  are  amenable 
to  machine  manipulation  and  analysis.  The  algebraic  style  of  Larch  traits  can  be  analyzed  by  rewrite-rule 
tools,  e.g.,  Reve[i8];  the  two-state  predicates  of  Larch  interfaces  and  thus,  task  predicates,  can  be 
analyzed  by  verification  systems  that  support  first-order  reasoning,  e.g.,  Gypsy,  HDM,  and  FDM 
[9,21,22];  formulae  in  real-time  logic  can  be  mechanically  transformed  into  equivalent  formulae  in 
Presburger  arithmetic.  However,  though  many  of  these  tools  are  available,  much  work  is  needed  to 
integrate  them  so  our  specifications  could  be  machine  checked  and  analyzed. 
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